Optimistic UI

たとえば「いいね」をクリックした時に、画面上は反応しているが、実際にはまだreqが完了していない、など

裏側の処理の都合でUIをblockしないようにする

server上に到達する前に画面を更新する

もし失敗したのであれば、更新前の状態にrollbackすれば良い

以下をちゃんと比較検討する

loadingを出すこと

Optimistic UIを使わない場合のデメリット

失敗した場合にrollbackすること

Optimistic UIを使う場合のデメリット

rollbackは体験としてはかなり悪い

失敗しづらいものであることを検討した上で採用すべき

どこもかしこも気軽に採用すべきではない。ちゃんと検討する

server側の更新ロジックを、client側にも書く必要がある

「いいね」の切り替えのようなかんたんなものならマシ

serverで複雑な処理をやるものの場合、clientにも同じコードを書かないといけなくなる

例えば「ツイートする」をOptimistic UIで作ろうとすると、

新しいツイートにはユニークなIDがついているはずだが、それはどこで生成するのか？

既存のツイートリストのどこに挿入するか

その間に、別のユーザーが他のモノを投稿した場合、どんな表示になるのか？

向いていそうなユースケース

「いいね」や「お気に入り」のtoggle表示

ロジックもかんたんだし、失敗した場合もさほど影響がない

待ち時間は大したこと無いし

向いていなさそうなユースケース

ブログ記事に投稿など

ロジックは複雑だし、

「投稿後に、投稿後のページに遷移する」のような仕様の場合、rollbackするのはかなり体験が悪い

データ量が増えると失敗する可能性は多少は上がるだろうし

この場合は、loadingを出したほうが良いだろう

react-queryについてのブログ

Optimistic UIを採用すべきかちゃんと検討しよう、ということも書いている